Forum PHP.pl

Pytania o streszczenie wątku, posty z "genialnymi" skryptami nadającymi się tylko na przedszkole i inne tego typu, będą bez ostrzeżenia usuwane przez moderatorów.
To mówiłem ja, Jarząbek... znaczy nospor dnia 2007-12-10
-------------------------------------------------------------------------------

SQL Injection (zwane też "SQL Insertion") to (rzekomo) najprostszy sposób włamu na stronę. Spowodowany jest on niepełnym sformułowaniem zapytań do MySQL.

Przykład. Dajemy na stronie możliwość edycji profilu. Zapytanie do SQL wygląda następująco:

[PHP] pobierz, plaintext 
<?php
$query = &#092;"update uzytkownicy set pole='$dane' where id='$id'\";
?>
[PHP] pobierz, plaintext 

Osoba włamująca się na stronę umieszcza całkiem prosty, odpowiedni ciąg znaków/poleceń w dowolnym polu edycji tego profilu, który wygląda np. tak (dla zmiany hasła użytkownika o dowolnie wybranym, przez atakującego numerze ID):

[PHP] pobierz, plaintext 
<?php
', haslo='nowe_haslo' WHERE id = '1
?>
[PHP] pobierz, plaintext 

W taki oto prosty sposób, osoba atakująca zmieniła hasło użytkownikowi o ID=1 (zazwyczaj administrator). W podobny sposób można również wyciągnąć dowolne dane z tabeli SQL.

W każdym razie. Poszperałem, pomyślałem i zebrałem wszystko do kupy. Zamieszczam to tutaj razem, oraz proszę o rozbudowanie tego topica, gdyż nie znalazłem na tym forum więcej informacji o "SQL Injection".

Oto co możemy dokonać:
1. Możemy sformułować nasze zapytanie do SQL tak:

[PHP] pobierz, plaintext 
<?php
$query = 'update `uzytkownicy` set `pole`=\"'.$dane.'\" where `id`=\"'.$id.'\";';
?>
[PHP] pobierz, plaintext 

2. Przy wstawianiu numerów ID do zapytań należy stosować tzw. rzutowanie typów:

[PHP] pobierz, plaintext 
<?php
$id = (int)$_GET['id'];
// lub
$id = intval($_GET['id']);
?>
[PHP] pobierz, plaintext 

3. Przy wstawianiu tekstów, należy wyciąć niebezpieczne znaki przy pomocy funkcji:

[PHP] pobierz, plaintext 
<?php
$string = mysql_real_escape_string($_POST['string']); // PHP5
 
$string = mysql_escape_string($_POST['string']); /* lub */ $string = addslashes($_POST['string']); // PHP4
?>
[PHP] pobierz, plaintext 

Może nie ma tego dużo, ale jest to już jakaś podstawa do zabezpieczenia strony/skryptu przed prostym i niezwykle niebezpiecznym, SQL Injection. Proszę osoby obeznane w tym temacie, aby dopisały tu własne propozycje metod zabezpieczenia się przed tym atakiem.

Ten post edytował Najki 14.02.2008, 10:04:12

Huh, z tego co pamiętam, to dało się też niektóre znaki zapisać korzystając z "wysokich kodów Unicode", a to już jest ciężko odfiltrować. (IMG:style_emoticons/default/winksmiley.jpg)

@SHiP, zdaje się, że masz pisać książkę o bezpieczeństwie www, więc powiedz mi... gdzie te Twoje "U/**/N/**/I/**/O/**/N" zadziała?

@pyro: ok trochę się zapędziłem. Sprawdziłem i w nowszych wersjach MySQL to nie działa.

W oracle można użyć czegoś takiego jak execute immediate i tam umieścić zapytanie zapisane w taki sposób jak podałem wyżej i ono zadziała.
W MS SQL można użyć exec()

A jako że piszemy o mysql(chyba?) to za pomocą /**/ można w nim ładnie pousuwać białe znaki np. takie zapytanie nie ma ani jednej spacji a działa:

[SQL] pobierz, plaintext 
SELECT/**/*/**/FROM/**/news;
[SQL] pobierz, plaintext 

EDIT:
albo coś jeszcze bardziej fajnego

[SQL] pobierz, plaintext 
/*!SELECT*//*!**//*!FROM*//*!news*/
[SQL] pobierz, plaintext 

To działa(sic!)

Ten post edytował SHiP 16.07.2010, 23:27:00

Jak niby wykorzystać funkcję char() ?
*, char można usuwać, a przed hex da się też zabezpieczyć.
Przyznaję, pomysł trochę nie za dobry ale można zrobić z tego log (IMG:style_emoticons/default/winksmiley.jpg)

Ten post edytował H4eX 17.07.2010, 13:38:33

[SQL] pobierz, plaintext 
SELECT char(80,72,80);
[SQL] pobierz, plaintext 

==

[SQL] pobierz, plaintext 
SELECT PHP
[SQL] pobierz, plaintext 

To zapytanie akurat nie działa (IMG:style_emoticons/default/winksmiley.jpg) (IMG:style_emoticons/default/cool.gif)

@darko: jaką masz wersję mysql? I czy masz w wybranej bazie tabelę news ;]

U siebie mam mysql Ver 14.14 Distrib 5.1.36, for suse-linux-gnu (x86_64) using readline 6.0 i dziala...

5.0.51a-24+lenny2+spu1 (Linux debian 2.6.30-bpo.1-686 #1 SMP Mon Aug 17 14:57:26 UTC 2009 i686 GNU/Linux) i nie hula. Oczywiście podałem nazwę istniejącej tabeli w bazie (IMG:style_emoticons/default/smile.gif) I zwraca całe nic (nie ma błędów po prostu nie zwraca żądnego wyniku, a dane w tabeli są na 100%).

Ten post edytował darko 17.07.2010, 13:54:06

Hmm no to dziwne. Wygląda na to, że starsza werjsa inaczej to interpretuje lub masz pustą tabelę. A coś takiego


(IMG:style_emoticons/default/questionmark.gif)

Wydzielcie ten nasz OT, jak możecie
/*!SELECT*//*!'advisors'*/;
to samo w mysql-query-browser v. 1.2.12:
Query executed in 0:00.0250. Query finished

To samo w phpmyadmin (phpMyAdmin - 2.11.8.1deb5+lenny3):
/*!SELECT*//*!'advisors'*/
Pokaż rekordy 0 - 0 (1 wszystkich, Wykonanie zapytania trwało 0.0003 sekund(y))

Dane są w tabeli advisors na milion %

Temat ma duzo strony czy ktoś mógłby wymienic wszystkie funkcje które chronia przed sql Injection

W sumie to faktycznie lekki śmietnik tu się zrobił.

Ogólnie to nie ma czegoś takiego jak "funkcja chroniąca przed SQL Injection". Temat jest bardziej złożony.
Najprościej jest przerzucić się w końcu na PDO i używać prepared statements


- Inne funkcje "chroniące przed SQL Injection" to mysql_real_escape_string, pg_escape_string, itp.

Stosuje się je do danych tekstowych i tylko dla odpowiedniego systemu bazodanowego.
Jeśli użyjemy funkcji wstawiającej ukośniki przed apostrofami ('O\'Reilly'), a w naszym systemie DB znakiem ucieczki jest drugi apostrof ('O''Reilly'), to nie dość że nie zabezpieczyliśmy się przed niczym, to jeszcze wstawiamy śmieci do bazy danych.

- W przypadku danych liczbowych używamy intval, floatval

- W przypadku nazw kolumn (np. do sortowania), to stosujemy:

[PHP] pobierz, plaintext 
<?php
 
$columns = array( 'date', 'points', 'level' );
 
// identyfikatory tekstowe lub liczbowe
if( $_GET['orderType'] < 0 || $_GET['orderType'] >= count( $columns ) )
{
    // ktoś próbuje mieszać, throw new Exception
}
 
$orderColumn = $columns[$_GET['orderType']];
$query = "SELECT (...) ORDER BY $orderColumn";
// zapytanie
 
 
// lub nazwy kolumn
if( !in_array( $_GET['orderType'], $columns ) )
{
    // ktoś próbuje mieszać, throw new Exception
}
 
$query = "SELECT (...) ORDER BY $_GET[orderType]";
// zapytanie
 
?>
[PHP] pobierz, plaintext 

- W przypadku MySQL zamiast popularnego addslashes poleca się używanie mysql_real_escape_string


- stripslashes jest praktycznie niepotrzebny. Przydaje się tylko, żeby oczyścić dane wejściowe ze śmieci jeśli mamy włączone magic_quotes_gpc

Rzutowanie będzie szybszym rozwiązaniem.

A co sądzicie o metodzie (na SELECT, UPDATE itp)

[SQL] pobierz, plaintext 
SELECT * FROM TABLE WHERE md5(column_name)='".md5($condition)."'; 
[SQL] pobierz, plaintext 

(IMG:style_emoticons/default/questionmark.gif)

Po co? Może wystąpić kolizja, choć to mało prawdopodobne, a poza tym po co dodatkowo obciążać PHP i bazę liczeniem hasha? Wystarczą prepared statements i SQL Injection masz z głowy.

Czy zastosowanie wyrazen regularnych z funkcja preg_match() do danych pochodzacych z formularza uchroni mnie od SQL Injection? Czy jest to niewystarczające zabezpieczenie?

Nie. A teraz przeczytaj temat.

Ja na każdym inpucie wprowadziłem preg_match jako głowną formę zabezpieczenia,żeby mi ktoś śmieci nie wpisywał dodatkowo użyłem funkcje, która dodatkowo filtruje, każdą wprowadzoną zmienną poprzez metody stripslashes,htmlentities,strip_tags i pomocniczo trim.Jednakże ,mam wątpliwość co do metody "htmlentities". Użyłem jej w taki sposób

[PHP] pobierz, plaintext 
$data= htmlentities ($data,ENT_QUOTES, 'UTF-8'); 
[PHP] pobierz, plaintext 

.Wiem ,że funkcja ma konwertować znaki specjalne do kodowani encji.Polskie znaki w tej metodzie ,są także postrzegane jako znaki specjalne,dlatego w metodzie użyłem zamiany encji na UTF-8 ,ale czy to ma sens???Czy np."\" nie zostanie z powrotem sprowadzony do postaci "\" zamiast do "amp&" która jest encją(IMG:style_emoticons/default/questionmark.gif) ?

A moje pytanie jest takie:

Czy jest gdzieś zestaw znaktów specialnych, bardzo często używanych w atach przez typu:
../
'--'
'<script>'
'onclick'
'char(
itd...

Myślę, że można zrobić funkcje, która przy każdym odświeżeniu strony będzie sprawdzać $_POST, $_GET, $_SERVER. w momencie, gdy któraś z tablic będzie zawierać słowo, z powyższej listy to damy bana na IP dla klienta. Wiadomo taki ban przed niczym nie zabezpieczy, ale skomplikuje trochę prace hakerowi i wytnie wszystkie boty, które nie zmieniają IP(ów).
Chciałbym tylko dostać jeśli ktoś posiada listę zwrotów, która nada się do zbudowania takiej funkcji, a o pomyśle co sądzicie?

@propage: A teraz wyobraź sobie, że tutaj na forum jest coś takiego. Piszesz sobie ładnie posta, dajesz wyślij i jesteś zbanowany. wtf?